Date: Tue, 7 Jun 94 04:30:07 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #112 To: tcp-group-digest TCP-Group Digest Tue, 7 Jun 94 Volume 94 : Issue 112 Today's Topics: Lurker needs info MSS and FTP throughput with JNOS/PI2 (2 msgs) nos-bbs mail address hosed? (2 msgs) TCP-Group Digest V94 #111 Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 6 Jun 94 11:16:49 EDT From: crompton@nadc.nadc.navy.mil (D. Crompton) Subject: Lurker needs info To: tcp-group@ucsd.edu, tsjwr@camelot.acf-lab.alaska.edu At crompton.nadc.navy.mil in /pub/internet are some files that may help. Doug ------------------------------ Date: Mon, 6 Jun 1994 13:36:30 -0800 (PDT) From: Glenn Elmore Subject: MSS and FTP throughput with JNOS/PI2 To: tcp-group@ucsd.edu Although I can't say that I really solved all the issues, I did manage to get things working pretty well with the PI cards and radios this weekend. The original problem I was having with MSS seems to have been solved by specifying MSS and window *before* the driver is attached to JNOS. The user is offered the opportunity to change these settings at any time but changes after the attach apparantly have no effect except to cause the indicated values to be incorrect. Thanks to John Ackerman, AG9V, who clued me into this characteristic of JNOS. It was in the docs too but I'd missed it. Once I modified the autoexec to correctly initialize mss and win, both at 1024 bytes, things ran pretty well. Approximate performance is as follows: ---------------------------------------------------------------------------- | radio speed | MSS | Window | FTP | % ch. capacity| data storage | | kbps | bytes | bytes |char/sec | | | ---------------------------------------------------------------------------- | 38.4 | 1024 | 1024 | 3450 | 72.5 | hard disk | | | | | 3850 | 80.2 | RAM disk | ---------------------------------------------------------------------------- | 57.6 | 1024 | 1024 | 5300 | 73.6 | hard disk | | | | | 5750 | 79.7 | RAM disk | ---------------------------------------------------------------------------- | 230.4 | 1024 | 1024 | 17600 | 61.1 | hard disk | | | | | 18500 | 64.2 | RAM disk | | | 1024 | 8192 | ~5000 | 17 | hard disk | ---------------------------------------------------------------------------- These are with TxDelay of 1 millisecond (PI minimum). But setting it to 2 ms only caused about a 1% decrease in throughput at 230.4 kbps. These numbers apply equally to wire or radio connections, though at 230.4 kbps some positions of the whip antenna which is on the #2 radio caused a few retries which dropped throughput drastically, down to 12000 kbps pretty easily. I suspect I have multipath or perhaps overload related issues running with both systems as they are, local to the garage at n6gn. As can be seen, large TCP Windows seem to be bad news. I'm not sure why. It's possible that DCD isn't working right, that I was running out of interrupt buffers or that ACKs aren't coexisting with incoming data somehow. This probably needs more investigation. At 230.4 kbps performance now seems good enough that I'm not very interested in spending a lot more time tuning things. I think it is fair to say that the PI cards can do onboard RxClock recovery just fine and that system performance is a pretty decent fraction of raw channel capacity. When doing transfers to hard disk at this rate, the drive access LED is pretty much a continuos blur. The 1.1 Megabytes of ZIPped JNOS sources transfers in about a minute. Now with the "more correct" JNOS configuration, a 50 mile, two hop, 38.4 kbps radio connection shows about 1100 char/sec throughput end-end. Hopefully we'll be able to upgrade the X1J TNC2 which is presently the middle node to a 386DX/PI-card and almost double this performance even before increasing the radio speed. Since the 230.4 kbps h/w changes have been made on all PI cards, we should be able to turn the entire system speed up remotely once we are ready. Thanks to all who replied with suggestions. More work remains to done with greater packet length and I still haven't gotten JNOS110D to do better than about 5000 char/sec with an Ethernet card but the JNOS/PI2 combination seems to be performing pretty well now. Glenn n6gn ------------------------------ Date: Mon, 6 Jun 1994 16:05:53 -0700 From: djc@intrepid.th.gov.bc.ca (Doug Collinge) Subject: MSS and FTP throughput with JNOS/PI2 To: tcp-group@ucsd.edu On Jun 6, 1:36pm, Glenn Elmore wrote: } As can be seen, large TCP Windows seem to be bad news. I'm not sure } why. It's possible that DCD isn't working right, that I was running out } of interrupt buffers or that ACKs aren't coexisting with incoming data } somehow. This probably needs more investigation. I noticed this phenomenon at 56k some time ago. It never got to the top of the stack of priorities so I never really looked into it - I just figured NOS TCP was broken in some way and forgot about it. } Thanks to all who replied with suggestions. More work remains to done } with greater packet length and I still haven't gotten JNOS110D to do } better than about 5000 char/sec with an Ethernet card but the JNOS/PI2 } combination seems to be performing pretty well now. I worked with packets up to 8KB and it made a substantial improvement on a very good channel. I'm not exactly sure why, since the decrease in ACK traffic could not account for the improvement. Perhaps it was better buffering or something. -- Doug Collinge djc@intrepid.th.gov.bc.ca Emerging Technology Ministry of Transportation and Highways, Province of British Columbia "40-Plus Oldies: where the hits are as soft as your gut!" - E. Harris ------------------------------ Date: Mon, 6 Jun 94 17:01:15 EDT From: crompton@nadc.nadc.navy.mil (D. Crompton) Subject: nos-bbs mail address hosed? To: brian@cyberpunk.ucsd.edu, tcp-group@UCSD.EDU Brian - Then can I assume that the MX procedure in NOS is broken? It appears to use this left to right approach - I.E. xxx.xxx.xxx.na (anything .na) gets a namibia mx record, or am I intepreting what you say wrong? Doug ------------------------------ Date: Mon, 6 Jun 1994 14:33:37 -0700 From: brian@nothing.ucsd.edu (Brian Kantor) Subject: nos-bbs mail address hosed? To: crompton@nadc.nadc.navy.mil, tcp-group@ucsd.edu If that's what NOS is doing, it's broken. - Brian ------------------------------ Date: Mon, 06 Jun 1994 20:01:49 -0400 (EDT) From: "Steve Dworkin, N2MDQ" Subject: TCP-Group Digest V94 #111 To: TCP-Group@ucsd.edu Brian: Thanks for your reply. I am not looking for a judicial comment, or even a judgement call, but rather how the system operates in terms of the format for passing you information. In addition, we will have to work out Bob's volunteerism locally. If there are any changes, we will let you know. Tnx and 73. Steve, N2MDQ n2mdq@delphi.com ------------------------------ End of TCP-Group Digest V94 #112 ******************************